Mapping configuration file data with static class fields or use IOptions<T> in ASP.NET Core

Mapping configuration file data with static class fields or use IOptions in ASP.NET Core

जुलाई 14, 2025

कंफीग्रेशन फाइल के डाटा की स्टैटिक क्लास के फील्ड्स के साथ मेपिंग

ASP.NET Core के अंतर्गत कई बार कंफीग्रेशन फाइल के डाटा को किसी स्टैटिक क्लास की फील्ड्स के साथ मेपिंग करके उसके भीतर स्टोर कर लिया जाता है और जब जरूरत होती है तो उस फील्ड्स को उपयोग कर लिया जाता है लेकिन इसका डिमैरिट यह है कि फील्ड्स स्टैटिक होने के कारण एप्लीकेशन स्तर पर सदैव मेमोरी में बना रहता है तो इसके बचने के लिए क्या उपाय है?

आइए इस बात पर विचार करते हैं. यह बात सत्य है और Real-world ASP.NET Core projects में अक्सर देखा गया pattern है, जो beginner से लेकर intermediate developers तक सहज रूप से अपनाते हैं:

👻“Configuration data को पढ़कर एक static class में स्टोर कर लो ताकि जब चाहे जहाँ से चाहे उसे एक्सेस कर सकें”

😞लेकिन इसका डिमेरिट (दोष) यह है कि:

पढ़ने में आसान भले ही हो, पर
टेस्टिंग कठिन हो जाता है,
लचीलापन नहीं रहता और,
डाटा मेमोरी में हमेशा बना रहता है, जिससे unnecessary pressure आता है।

समस्या को थोड़ा गहराई से समझें:

⚠️ जब आप ऐसा करते हैं:


public static class ConfigValues
{
    public static string EmailHost { get; set; }
    public static string EmailUser { get; set; }
}

और फिर startup में:


ConfigValues.EmailHost = config["SmtpSettings:Host"];
ConfigValues.EmailUser = config["SmtpSettings:Username"];

तो आपने वस्तुतः डेटा को global static memory में रख दिया।
अब:

यह न कभी GC (Garbage Collected) होता है
न आप per-request या per-environment customization कर सकते हैं
न ही scoped DI का लाभ मिलता है

समाधान – क्या करें?

1. Configuration Binding with IOptions<T> (Recommended Way)

ASP.NET Core का पूरा configuration infrastructure इस मकसद से तैयार किया गया है कि आप config को POCO classes में bind करें और DI (Dependency Injection) से उसे inject करें।

Step-by-step:

🔹 SmtpSettings.cs


public class SmtpSettings
{
    public string Host { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
}

🔹 appsettings.json


{
  "SmtpSettings": {
    "Host": "smtp.example.com",
    "Username": "abc@example.com",
    "Password": "secret"
  }
}

🔹 Program.cs में bind करें:

builder.Services.Configure<SmtpSettings>(
    builder.Configuration.GetSection("SmtpSettings"));

🔹 जहां जरूरत हो वहां inject करें:


using Microsoft.Extensions.Options;
public class EmailSender
{
    private readonly SmtpSettings _smtp;
    public EmailSender(IOptions<SmtpSettings> options)
    {
        _smtp = options.Value;
    }
    public void Send()
    {
        var host = _smtp.Host;        // use host...   
    }
}

फायदे:

लाभ	विवरण
🔄 Auto-binding	config section से class को bind करना
📦 Dependency Injection	scoped/lifetime-based access
🧹 GC Friendly	कोई static memory leak नहीं
🔁 Configurable per environment	dev/prod/env vars etc. से भी bind हो सकता है
🧪 Testable	mock config inject करना आसान

2. Reloadable Configuration – IOptionsSnapshot<T> (Scoped, reloadable)

अगर आपको ऐसी settings चाहिए जो हर request पर reload हो सकें (e.g. dev environment में):


using Microsoft.Extensions.Options;
public class EmailSender
{
    private readonly SmtpSettings _smtp;
    public EmailSender(IOptionsSnapshot<SmtpSettings> options)
    {
        _smtp = options.Value;
    }
}

IOptionsSnapshot<T> → Scoped lifetime, हर request पर नया value लाता है

3. Singleton-safe alternative (अगर कोई config सिर्फ singleton में चाहिए)


public class AppInfo
{
    public string Version { get; set; }
}
builder.Services.Configure<AppInfo>(builder.Configuration.GetSection("AppInfo"));

Inject it into a singleton safely via:


using Microsoft.Extensions.Options;
public class SingletonService
{
    private readonly string _version;
    public SingletonService(IOptions<AppInfo> options)
    {
        _version = options.Value.Version;
    }
}

Static Config Class से क्यों बचें?

दोष	विवरण
Memory हमेशा रिज़र्व रहती है	GC नहीं कर सकता
Testability नहीं	Unit test में override करना कठिन
Hardcoded dependency	loosely-coupled code design नहीं बनता
Environment variation नहीं	Dev/Test/Prod को handle करना कठिन

निष्कर्ष

मार्ग	उचित है?	उपयोग कब करें
Static class config	नहीं	सिर्फ छोटा console app हो तो चल सकता है
Singleton with DI	सीमित	rarely-changing config
IOptions<T>	श्रेष्ठ	लगभग सभी उपयोग में
IOptionsSnapshot<T>	Scoped reload	per-request freshness
IOptionsMonitor<T>	dynamic runtime updates	background services में ज़्यादा उपयोगी

यह ब्लॉग खोजें

तकनीकी ज्ञान - अपनी भाषा में